Detecting sources of computer network failures

ABSTRACT

Methods, systems, and apparatus, including computer programs encoded on computer storage media, for detecting sources of computer network failures. One of the methods includes identifying a network flow in a computer network between a source and a destination; performing a first probe to determine whether there is end-to-end connectivity between the source and the destination; in response to determining that there is no end-to-end connectivity between the host and the destination, performing one or more additional probes including a second probe to determine whether each hop in the path of the network flow between the source and the destination is operational including requesting that the source transmit a respective first trace diagnostic packet to each hop in the path of the network flow; and determining whether at least one link of the computer network that is part of the path of the network flow has failed based on the results.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of, and claims priorityto, U.S. patent application Ser. No. 16/817,174, filed on Mar. 12, 2020,now allowed, and U.S. patent application Ser. No. 15/809,836, filed onNov. 10, 2017, now U.S. Pat. No. 10,601,644. The disclosure of theforegoing application is incorporated here by reference.

BACKGROUND

This specification relates to detecting sources of computer networkfailures. A typical computer network includes multiple computersconnected together through one or more links and one or more networkdevices, e.g., switches or routers. Computer networks can experiencepartial or total failure for many reasons, including the failure of oneor more components of the computer network. For example, the failure ofsome links in a computer network can cause problems in transmittingcertain network flows. The diagnostic logic of network devices in thenetwork may fail to detect such link failures, which in turn can cause asituation where the computer network continues to use failed links forpacket forwarding. Detecting sources of computer network failures may bedifficult because it may not be practicable or feasible to investigateevery component of a computer network. This is especially the case forlarger networks with numerous hosts, links, and switches.

SUMMARY

In general, this specification describes techniques for detectingsources of network failures. In particular, this specification describestechniques that use end-to-end probing with diagnostic packets formattedin a manner that cause switches to forward the diagnostic packets alongthe same path of packets of a particular network flow. Thisspecification further describes techniques that use trace probing withdiagnostic packets formatted in a manner that causes hops on their pathto send a response to the diagnostic packet to the source host.

In general, one innovative aspect of the subject matter described inthis specification can be embodied in methods that include the actionsof identifying a network flow in a computer network between a source anda destination; performing a first probe to determine whether there isend-to-end connectivity between the source and the destination includingrequesting that the source transmit an end-to-end diagnostic packet tothe destination, wherein the end-to-end diagnostic packet includesinformation that causes one or more network devices in the computernetwork to forward the end-to-end diagnostic packet on the path of thenetwork flow; in response to determining that there is no end-to-endconnectivity between the host and the destination, performing one ormore additional probes including a second probe to determine whethereach hop in the path of the network flow between the source and thedestination is operational including requesting that the source transmita respective first trace diagnostic packet to each hop in the path ofthe network flow, each trace diagnostic packet having information thatcause the respective hop to send a first trace response packetresponsive to the first trace diagnostic packet to the source; anddetermining whether at least one link of the computer network that ispart of the path of the network flow has failed based on the results ofthe first probe and the one or more additional probes. Other embodimentsof this aspect include corresponding computer systems, apparatus, andcomputer programs recorded on one or more computer storage devices, eachconfigured to perform the actions of the methods.

This specification uses the term “configured” in connection withsystems, apparatus, and computer program components. For a system of oneor more computers to be configured to perform particular operations oractions means that the system has installed on it software, firmware,hardware, or a combination of them that in operation cause the system toperform the operations or actions. For one or more computer programs tobe configured to perform particular operations or actions means that theone or more programs include instructions that, when executed by dataprocessing apparatus, cause the apparatus to perform the operations oractions. For special-purpose logic circuitry to be configured to performparticular operations or actions means that the circuitry has electroniclogic that performs the operations or actions.

The foregoing and other embodiments can each optionally include one ormore of the following features, alone or in combination. In particular,one embodiment includes all the following features in combination.Performing the one or more additional probes includes performing a thirdprobe to determine whether each hop in a path between the destinationand the source is operational including requesting that the destinationtransmit a respective second trace diagnostic packet to each hop in thepath between the destination and the source, each trace diagnosticpacket having information that cause the respective hop to send a secondtrace response packet responsive to the second trace diagnostic packetto the source host. The second trace diagnostic packet associated with arespective host has a particular value in a time-to-live field of thesecond trace diagnostic packet that causes the hop to send a timeexceeded message to the host in response to the second trace diagnosticpacket. The end-to-end diagnostic packet has a source identifier fieldand a destination identifier field that include identifiers of thesource and destination respectively. The end-to-end diagnostic packethas specified values in one or more particular fields to indicate thatthe end-to-end diagnostic packet is a diagnostic packet. The diagnosticpacket is a Transport Control Protocol packet, and wherein the specifiedvalues comprise zero values for a flags field. The first tracediagnostic packet associated with a respective hop has a particularvalue in a time-to-live field of the first trace diagnostic packet thatcauses the hop to send a time exceeded message to the host in responseto the first trace diagnostic packet.

Performing the first probe further includes: determining whether thesource has received an end-to-end response packet responsive to theend-to-end diagnostic packet; in response to determining that the sourcehas received the end-to-end response packet, determining that there isend-to-end connectivity between the source and the destination; and inresponse to determining that the source has not received the end-to-endresponse packet, determining that there is no end-to-end connectivitybetween the source and the destination.

The method further includes: determining whether the source has receivedthe first trace response packet from a particular hop; in response todetermining that the source has received the first trace response packetfrom a particular hop, determining that the particular hop isoperational; and in response to determining that the source has notreceived the first trace response packet from a particular hop,determining that the particular hop is not operational.

Identifying the network flow includes: obtaining retransmissioninformation from one or more hosts in the computer network; analyzingthe re-transmission information to detect one or more network flows; foreach network flow of the one or more network flows, determine are-transmission count from the re-transmission information; identify agroup of the one or more network flows whose re-transmission countexceeds a threshold; and selecting the network flow from the group.Identifying the network flow further includes: for each network flow inthe group, detecting if a destination of the network flow has failed;and updating the group to exclude any network flow whose correspondingdestination has failed.

The method further includes generating probe result information thatinclude results of the first probe, the second probe, and the thirdprobe; analyzing the probe results to determine a visit count and afailure count for each link in the network, the visit count for acorresponding link indicating a number of times that packets havetraveled the link and the failure count for a corresponding linkindicating a number of times that the link has shown signs of failure;and generating a graph of the computer network, the graph includingedges that each correspond to a respective link in the computer networkand weights for each edge that are determined based on at least one ofthe visit count and the failure count for the link corresponding to theedge. The method further includes analyzing the graph to detect at leastone link in the computer link that has likely failed.

In general, one innovative aspect of the subject matter described inthis specification can be embodied in methods that include the actionsof obtaining retransmission information from one or more hosts in acomputer network; analyzing the re-transmission information to detectone or more network flows; for each network flow of the one or morenetwork flows, determine a re-transmission count from there-transmission information; identify a group of the one or more networkflows whose re-transmission count exceeds a threshold; and generatingone or more network diagnostic conclusions about the identified group.Other embodiments of this aspect include corresponding computer systems,apparatus, and computer programs recorded on one or more computerstorage devices, each configured to perform the actions of the methods.

Particular embodiments of the subject matter described in thisspecification can be implemented so as to realize one or more of thefollowing advantages. Computer networks can be probed for failuresassociated with particular network flows. The accuracy of networkdiagnostic results can be improved by active probing while limiting theamount of active probing that needs to be performed. Data from networkdiagnostics can be processed in a manner that allows for graph-basedinferences and calculations. Performance of more computationallyintensive probing tasks can be limited by selecting network flows onwhich those tasks will be performed using less computationally intensiveprobing methods and passive methods that do not probe the network, thusreducing the overall cost of performing network diagnostics.

The details of one or more embodiments of the subject matter of thisspecification are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages of thesubject matter will become apparent from the description, the drawings,and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an example computer network including anetwork diagnostic engine.

FIG. 2 is a block diagram of an example network diagnostic engine.

FIG. 3 is a flow diagram of an example process for performing anend-to-end probe followed by a trace probe.

FIGS. 4A and 4B are data flow diagrams for an end-to-end probe and atrace probe respectively.

FIGS. 5A-5D are example representations of diagnostic packets.

FIG. 6 is a flow diagram of an example process for classifying networkflows based on re-transmission counts.

FIG. 7 is a flow diagram of an example process for detecting hostfailures.

FIG. 8 is a flow diagram of an example process for generating a graphwith network link reliability information.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example computer network 100 including anetwork diagnostic engine 101. The network diagnostic engine 101 is asystem of one or more computers on which the techniques described inthis specification can be implemented. The computer network 100 may be,for example, a network used to connect multiple data server hosts in adistributed data center.

The network diagnostic engine 101 monitors availability and reliabilityof one or more components, e.g., switches, host computers, and/or links,of the computer network 100. The network diagnostic engine 101 canrequest that host computers in the computer network 100 perform certainfunctionalities and obtain information from host computers about statusof the computer network 100. The network diagnostics engine 101 can usethe information obtained from the host computers to detect one or morecomponents of the computer network 100 that may be experiencingdifficulties. In some implementations, the network diagnostic engine 101can use the information to generate a representation, e.g., a graph, ofinformation about usage and/or reliability of one or more components ofthe computer network 100. An example network diagnostic engine 101 isdescribed in greater detail below with reference to FIG. 2.

The computer network 100 includes multiple host computers, i.e., host A111, host B 112, host C 113, and host D 114. The host computers areconnected to each other through multiple switches, i.e., switch A 141,switch B 142, switch C 143, switch D 144, switch E 145, switch F 146,switch G 147, and switch F 148. Two switches or a switch and a host areconnected to each other through a link in the computer network 100. Alink is a physical connection that may correspond to an interface in aswitch.

Each host has a communication module, specifically, communication ModuleA 121 in host A 111, communication Module B 122 in host B 112,communication Module C 123 in host C 113, and communication Module D 124in host D 114. The communication module in a given host sendscommunication packets, e.g., transport control protocol (TCP) packets oruser datagram protocol (UDP) packets, from the host to a switch andreceives communication packets to the host from a switch.

A switch is an example computer networking device that receives,processes, and forwards communication packets in a computer network.While this specification refers to switches, the techniques described inthis specification may apply to computer networks that use other typesof computer networking devices capable of receiving, processing, andforwarding communication packets in a computer network, such as routersand Ethernet hubs.

Each switch can receive communication packets from one or more hostcomputers and/or one or more other switches. When a switch receives acommunication packet, the switch selects a feasible path for forwardingthe packet and, based on the selected path for the packet, determines anext hop, i.e., host or switch, to forward the packet to. For example,if switch A 141 receives a packet from host A 111 intended for host D114, switch A can choose the path Switch A 141→Switch E 145→Switch D144→host D 114 for the packet and forward the packet to Switch E 145,the next hop in the selected route.

In some situations, the switch may determine that there are multiplefeasible paths between a source host and a destination host. Forexample, if switch A 141 receives a packet from host A 111 intended forhost D 114, switch A 141 can determine that the path Switch A 141→SwitchE 145→Switch D 144→host D 114, the path Switch A 141→Switch F 146→SwitchD 144, and many other paths are feasible paths to forward the packetfrom source host A 111 to destination host D 114.

The switch can use a forwarding algorithm to select a path to forward apacket when there are multiple available paths between the source andthe destination of the packet. While a forwarding algorithm can selectany path between the source and the destination for a packet, someforwarding algorithms aim to route packets associated with a networkflow along a same path. A network flow can be characterized bycommunication between a source host and a destination host within aparticular time frame.

In some implementations, the forwarding algorithm uses information froma packet header to select a route. For example, the forwarding algorithmcan use identifiers, e.g., internet protocol (IP) addresses, of a sourceand a destination of the communication packet, an identifier of a sourceand destination port (such as a source TCP port and a destination TCPport) of the communication packet, and a transport protocol identifierof the communication, to select a route. For example, the switch mayapply a switch-specific hashing function to the IP addresses of thesource and the destination, the source and destination TCP ports, andthe transport protocol identifier of a communication packet to generatea hash value for the packet, and use the hash value to select a pathbetween the source and the destination of the packet among multiplefeasible paths. As a result, the forwarding algorithm will route allpackets of a given network flow between the source and the destinationhosts along the same path.

Some forwarding algorithms that use an identifier of the source anddestination of a communication packet to select a path to forward apacket also rely on a forwarding strategy called equal-cost, multi-pathforwarding (ECMP). A switch using ECMP may obtain an estimate of a costassociated with each feasible path between a source and a destination ofa communication packet, e.g., based on the number of links between hopsthat the packet would have to pass to reach the destination and anestimated cost associated with each link (e.g., determined based on alength and/or speed of the link), and select a path having a lowestestimate of cost to forward the packet. If there are multiplelowest-cost paths available between the source and destination host, theswitch may choose a lowest cost path based on one or more additionalfactors, such as the identifier of the source and the destination of thecommunication packet, the identifier of the source and destination portsfor the communication packet, and the transport protocol identifier. Forexample, the switch may hash the identifier of the source communicationpacket, the identifier of the destination communication packet, theidentifier of the source port, the identifier of the destination port,and the identifier of the transport protocol. The switch may use theresulting hash value to select a path between the source and thedestination of the packet among multiple lowest-cost paths. Thisforwarding technique can cause the computer network 100 to distributepackets among multiple paths of equal cost and reduce the possibility ofoverloading a particular path. This forwarding technique can also causethe computer network 100 to forward communication packets belonging to aparticular network flow along the same path at least for a period oftime.

Each host includes a diagnostic module, i.e., i.e., diagnostic Module A121 in host A 111, diagnostic Module B 122 in host B 112, diagnosticModule C 123 in host C 113, and diagnostic Module D 124 in host D 114. Adiagnostic module in a host executes functionalities requested by thenetwork diagnostic engine 101 and provides information to the networkdiagnostic engine 101 about a status of the computer network 100.

For example, the network diagnostic engine 101 can request that adiagnostic module on a host sends, e.g., using the communications moduleof the host, a diagnostic packet from the host to a particulardestination. The diagnostic module can obtain information about thetransmission of a diagnostic packet within the computer network 100,e.g., based on communication packets received in response to the packet,and provide the obtained information to the network diagnostic engine101. The transmission and reception of diagnostic packets is describedin greater detail below.

FIG. 2 is a block diagram of an example network diagnostic engine 101.The network diagnostic engine 101 includes an initial detectionsub-engine 211, a probe sub-engine 212, and a data analysis sub-engine213.

The initial detection sub-engine 211 detects one or more network flows251 that the probe sub-engine 212 can probe. A network flow is a flow ofcommunication packets between a source and a destination. The computernetwork 100 may transmit packets pertaining to many network flows.Probing a network flow using the probe sub-engine 212 can be acomputationally intensive task. By reducing the number of network flowsthat the probe sub-engine 212 needs to probe, the initial detectionsub-engine 211 can increase the efficiency of the network diagnosticengine 101.

The initial detection sub-engine can include a high re-transmissiondetector 221 and a host failure detector 231. The high re-transmissiondetector 221 receives information about packet retransmissions fornetwork flows from one or more hosts and processes the obtainedinformation to determine one or more network flows whose retransmissioncount exceeds a threshold value. The high re-transmission detector 221may determine that such high-retransmission network flows requirefurther investigation for potential problems and can transmitidentifiers of those network flows to the host failure detector 231 orto the probe sub-engine 212. Detecting network flows having highretransmission counts is described in greater detail below withreference to FIG. 6.

The host failure detector 231 determines whether a particular hostinvolved in transmitting or receiving network flow, for example anetwork flow with high re-transmission as detected by the highre-transmission detector 221 and/or a network flow having otherparticular properties as detected by one or more detection techniques,has failed. The host failure detector 231 can request that a host, e.g.,the source host, send a status inquiry packet to the particular host andobtain information from the source host about whether the source hosthas received a response to the status inquiry packet. The host can sendthe status inquiry packet over one or more possible paths in thecomputer network 100, including paths that are different than a pathassociated with a network flow between the source host and thedestination host. Because of the information used by the forwardingalgorithm, the paths for transmitting the status inquiry packet mostlikely include paths different than a path associated with a networkflow between the source host and the destination host. The host failuredetector 231 can process the obtained information to determine if theparticular host has failed. Detecting a host failure is described ingreater detail below with reference to FIG. 7.

When the host failure detector 231 determines that a host associatedwith a network flow has failed, the network diagnostic engine 101 candetermine that a host failure (as opposed to other network failures suchas a failure of switches and/or links) is a likely reason for any signsof problematic performance, e.g., high retransmission count, associatedwith the network flow. Therefore, the network diagnostic engine 101 canexclude the network flow affected by host failure from a group ofnetwork flows being probed by the probe sub-engine 212. This can furtherlimit the group of network flows that need to be probed by the probesub-engine 212 and thus increase the efficiency of the networkdiagnostic engine 101.

The probe sub-engine 212 performs at least one of two types of probingon the network flows 251: “end-to-end probing” and “trace probing.”End-to-end probing is performed by an end-to-end prober 222 of the probesub-engine 212. Trace probing is performed by a trace prober 232 of theprobe sub-engine 212. The probe sub-engine transmits results 252 of theprobes to a data analysis sub-engine 213.

The end-to-end prober 222 requests that a source host sends anend-to-end diagnostic packet to a destination host and obtainsinformation about whether the source host has determined that thedestination host has received the end-to-end diagnostic packet. Thenetwork diagnostic engine 101 can process the obtained information todetermine if a network flow transmitted along the same path as thediagnostic packet has end-to-end connectivity between the source and thedestination of the network flow. If the network diagnostic engine 101determines that a network flow does not have such end-to-endconnectivity, the end-to-end prober 222 can request that the traceprober 232 further probe the path taken by the network flow using traceprobing.

The trace prober 232 requests that a host sends a trace diagnosticpacket for every expected hop in a path corresponding to a network flowand obtains information about whether each expected hop has received acorresponding trace diagnostic packet. The network diagnostic engine 101can process the obtained information to determine whether any link inthe path has failed. End-to-end probing and trace probing are describedin greater detail below with reference to FIG. 3.

The data analysis sub-engine 213 receives the probe results 252 from theprobe sub-engine 212 and can analyze the probe results 252. Analysis caninclude providing particular output results or generating arepresentation of availability and reliability of components of thecomputer network 100 and detect one or more components of the computernetwork 100 that may be experiencing difficulties.

The data analysis sub-engine 213 can include a graph constructor 223, afalse positive corrector 233, and a network failure detector 243. Thegraph constructor 223 processes the probe results 252 to generate agraph. The graph includes edges corresponding to links in the computernetwork 100, nodes corresponding to switches and optionally hosts in thecomputer network 100, and edge weights corresponding to an estimate ofreliability of the link.

Generating a graph is described in greater detail below with referenceto FIG. 8.

The graph constructor 223 can determine the estimate of reliability fora link based on a count of diagnostic packets observed to have traveledthe link, i.e., a visit count for the link, and a count of packetsobserved to have been lost on the link, i.e., a failure detector for thelink. This may lead to situations where the graph constructor 223determines that a link has a low estimate of reliability because thelink has a low visit counter. However, in some situations, a low visitcounter for a link can result from a low utilization of the link in thenormal course of network 100 activity and not from a failure of thelink. To correct such false positive detections, the false positivedetector 233 can detect low utilization links, e.g., by detecting linkswhose visit count is below a threshold. The false positive detector 223can then request that the trace prober 232 of the probe sub-engine 233generate trace diagnostic packets for network flows whose correspondingpath includes the low utilization links in order to increase network 100activity on those links and increase the accuracy of the probe results252.

The network failure detector 243 obtains the graph generated by thegraph constructor 223 and analyzes estimates of reliability for thelinks in the graph to detect links that are likely to have failed. Insome implementations, the network failure detector 243 determines thatlinks whose estimate of reliability falls below a threshold likely havefailed.

FIG. 3 is a flow diagram of an example process for performing anend-to-end probe followed by a trace probe. The process can be performedby a system of one or more computers, e.g., the network diagnosticengine 101 of FIG. 1.

The system identifies a network flow (302) and requests that a sourcehost associated with the network flow transmit an end-to-end diagnosticpacket corresponding to the network flow to a destination hostassociated with the network flow (304). For example, the network flowcan be identified based on analyzing retransmission information obtainedfrom one or more hosts to identify candidate flows for furtherinvestigation.

The end-to-end diagnostic packet should have a particular format thatcauses switches to forward the packet along the same path as a pathcorresponding to the monitored network flow. For example, if theswitches use an identifier of the source and destination of a packet toselect a path to forward the packets of the flow, an end-to-enddiagnostic packet is configured to have the same source and destinationidentifiers as the source and destination identifiers characterizing theparticular network flow. This causes the diagnostic packet to beforwarded along the same path as the corresponding network flow. Withoutensuring that the packet will follow the same path as packets of theflow, the diagnostic packet could be sent along a different path fromthe source host to the destination host. Thus, it would otherwise bedifficult to determine whether there was a problem along the particularpath of the flow. The format of the end-to-end diagnostic packet for anetwork flow is also configured to be distinct from the format of aregular packet of the network flow in a way that allows a program on thedestination host, e.g., a diagnostic engine on the destination host, todetermine that the packet is a diagnostic packet (and not a normalpacket in the flow) and thus send a corresponding diagnostic packet inresponse. For example, the end-to-end diagnostic packet can havespecified values, e.g., zero values, in certain fields. This can causethe packet to be ignored by a communications module of the destinationhost and thus not interfere with the transmission of normal packets of anetwork flow. The format of an example end-to-end diagnostic TCP packetis described in greater detail below with reference to FIG. 5A.

The system determines if the source host has received an end-to-endresponse packet (306). The end-to-end response packet is an indicationthat the destination host, e.g., a diagnostic module in the destinationhost, has received the end-to-end diagnostic packet. The end-to-endresponse packet is configured to have a format that indicates that it:(1) is a diagnostic packet and not a normal network flow packet (e.g.,by having specified values in certain fields); and (2) is in response tothe end-to-end diagnostic packet (e.g., by having source and destinationidentifiers that correspond to the destination and source identifiers ofthe end-to-end diagnostic packet respectively). The format of an exampleend-to-end diagnostic TCP packet is described in greater detail belowwith reference to FIG. 5B.

If the system determines that the source host has received theend-to-end response packet, it generates probe results (316) based onthe results of the end-to-end probe performed in steps 304 and 306.However, if the system determines that the source host has not receivedthe end-to-end response packet, the system decides that the network flowneeds further probing in the form of a trace probe by the source hostalong the path of the end-to-end diagnostic packet (steps 308 and 310).After performing the trace probe, the system generates the probe results(312) based on the results of the end-to-end probe and the trace probe.

To perform the trace probe, the system requests that the source hosttransmit a trace diagnostic packet (308) corresponding to each expectedhop, e.g., host and switch, in a path between the source host and thedestination host and determines if the source host has received a traceresponse packet corresponding to each trace diagnostic packet (310). Atrace response packet corresponding to a trace diagnostic packet is anindication that the expected hop corresponding to the trace diagnosticpacket has received the trace response packet.

Each trace diagnostic packet corresponding to a particular hop isconfigured to have a particular format that: (1) can cause theparticular hop to send a trace response packet corresponding to thetrace diagnostic packet; and (2) has identifying information that thecorresponding hop can put in the trace response packet to identify thetrace diagnostic packet being responded to. Each trace response packetin turn has a particular format that includes identifying information ofa corresponding trace diagnostic packet.

For example, a trace diagnostic packet corresponding to a hop can be aTCP or UDP packet whose time-to-live (TTL) field has been set by thesource host such that it will expire at the hop and cause the hop tosend a trace diagnostic response in the form of a time-exceeded message.A time-exceeded message is an example of an internet control messageprotocol (ICMP) message that can contain a collection of bytes, e.g.,the first 64 bytes, of a packet that triggered the time exceededmessage, i.e., the corresponding trace diagnostic packet. Therefore, theidentifying information of the trace diagnostic packet can be in aportion of the trace diagnostic packet that the system includes as aportion of the time exceeded message. For example, if the time exceededmessage includes the first 64 bytes of the packet that triggered thetime exceeded message, the identifying information of a trace diagnosticpacket can be in the first 64 bytes of the trace diagnostic packet,e.g., in the sequence number of a TCP packet or the length field of aUDP packet, so that the system will include those identifyinginformation in the time exceeded message. Some of the length values forIP header fields noted in this specification refer to a format ofcommunications packets that follow the version 4 of the IP protocol(IPv4). Other versions of the IP protocol may use other formats.

An example TCP trace diagnostic packet is described in greater detailbelow with reference to FIG. 5C. An example ICMP trace response packetis described in greater detail below with reference to FIG. 5D.

FIGS. 4A and 4B are data flow diagrams for an end-to-end probe and atrace probe respectively. FIG. 4A depicts an end-to-end diagnosticpacket 411 sent from a source host 401 to a destination host 402 and acorresponding end-to-end response packet sent from the destination host402 to the source host 401. The source host 401 can send the end-to-enddiagnostic packet 411 as part of a sequence of packets and thus with asequence number. The destination host 402 can send the end-to-endresponse packet 412 as a single packet of a sequence with anacknowledgement number that corresponds to the sequence number of theend-to-end diagnostic packet 411.

FIG. 4B depicts two trace diagnostic packets sent from the source host401. The first one, trace diagnostic packet 1 421, has a TTL value of 1and thus decrements and expires at the first hop on its route, i.e., theswitch 403. The second trace diagnostic packet, i.e., trace diagnosticpacket 422, has a TTL value of 2, and thus gets transmitted to thedestination host 402 by the switch 403. The second trace diagnosticpacket 422 then expires at the destination host 402.

FIG. 4B also depicts two trace response packets. In response to thefirst trace diagnostic packet 421, the switch 403 sends a first traceresponse packet, i.e., trace response packet 1 431, with an arbitraryTTL value, e.g., 64, to the source host 401. In response to the secondtrace diagnostic packet 422, the destination host 402 sends a secondtrace diagnostic packet, i.e., trace diagnostic packet 2 432, with anarbitrary TTL value to the source host 401. The switch 403 receives andtransmits the second trace response packet 432 to the source host 401.

FIGS. 5A-5D are example representations of diagnostic packets. All thediagnostic packets illustrated have an IP header 501 that includes a32-bit source address field 521, a 32-bit destination address field 523,and an 8-bit TTL field 518. The source address field 521 includes anidentifier of the source of the packet and the destination address field522 includes an identifier of the destination of the packet. The TTLfield 518 is decremented at each hop and, when it reaches zero at a hopbefore destination, causes a hop to send a time exceeded message to thesource of the packet.

FIGS. 5A-5C are example TCP packets that include a TCP payload 502. TheTCP payload includes a 32-bit sequence number 534, a 32-bitacknowledgement number 535, a 4-bit offset value 536, a 6-bit reservedvalue 537, a 6-bit value containing flags 538, and a 16-bit window sizevalue 539. The sequence number 534 indicates the position of aparticular packet in a sequence of packets and the acknowledgementnumber 535 indicates the sequence number 534 of an original packet whosereceipt is being acknowledged by the particular packet.

FIG. 5A depicts an example TCP end-to-end diagnostic packet. The sourceaddress field 521 of the packet is the IP address of a source hostassociated with a monitored network flow, while the destination addressfield 522 of the packet is the IP address of a destination hostassociated with the monitored network flow. The sequence number 534 ofthe packet can distinguish the packet in a group of packets and theacknowledgement number of the packet is zero to indicate that the packetis not an end-to-end response packet. The offset value 536, the reservedvalue 537, the flag bits 538, and the window size 539 of the packet areset to zero to indicate that the packet is a diagnostic packet.

FIG. 5B depicts an example TCP end-to-end response packet. The sourceaddress field 521 of the packet is the IP address of a destination hostassociated with a monitored network flow, while the destination addressfield 522 of the packet is the IP address of a source host associatedwith the monitored network flow. The sequence number 534 of the packetis zero because the packet is not an end-to-end diagnostic packet andthe acknowledgement number 535 of the packet is set to the sequencenumber 534 of an end-to-end diagnostic packet that the end-to-endresponse packet acknowledges. The offset value 536, the reserved value537, the flag bits 538, and the window size 539 of the packet are set tozero to indicate that the packet is a diagnostic packet.

FIG. 5C depicts an example TCP trace diagnostic packet. The sourceaddress field 521 of the packet is the IP address of a source hostassociated with a monitored network flow, while the destination addressfield 522 of the packet is the IP address of a destination hostassociated with the monitored network flow. The TTL field 518 of thepacket is a value that, if decremented at each hop, will reach zero at aparticular hop that the packet seeks to trace. The sequence number 534of the packet includes an identifying value for the packet. The offsetvalue 536, the reserved value 537, the flag bits 538, and the windowsize 539 of the packet can be zero to indicate that the packet is adiagnostic packet. A number of different TCP trace diagnostic packetscan be sent with different TTL values to capture successive hops in thepath of the flow.

FIG. 5D depicts an example trace response packet in the form of an ICMPtime-exceeded message. The ICMP payload of the packet includes an ICMPheader 551 and an ICMP body 554. The ICMP header 551 includes an 8-bittype field 552 and an 8-bit code field 553 set to eleven and zerorespectively to indicate that the ICMP message is a time exceededmessage, a 16-bit checksum field 556, and a 32-bit field with otherheader information 555. The ICMP body 554 can include a portion, e.g.,the first 32 bytes, of the packet that triggered the ICMP message. Ifthe triggering packet is a TCP trace diagnostic packet as depicted inFIG. 5C, an identifying number in the sequence number field 534 of thetriggering packet will also appear in the ICMP body 554 of the traceresponse packet. As a result, the origin of each received ICMP timeexceeded message can be determined from the identifying information inthe returned portion of the packet.

FIG. 6 is a flow diagram of an example process 600 for classifyingnetwork flows based on re-transmission counts. The process 600 will bedescribed with respect to a system that can perform the process 600,e.g., the network diagnostic engine 101 of FIG. 1.

The system identifies one or more network flows (602) and obtainsinformation about re-transmission of packets associated with the networkflows from one or more hosts (604).

In some implementations, the system generates information aboutre-transmission of packets associated with the network flows by tracing,on each host of the one or more hosts, calls to a kernel function usedfor packet re-transmission and then mapping each call to correspondingidentifying information in accordance with a network protocol. Forexample, the system can trace calls to the tcp_retransmit_skb() functionused for TCP packet re-transmission in Linux. Subsequently, the systemtraces are passed to one or more data structures used by thetcp_retransmit_skb() function, e.g., struct sock and struct sk_buff datastructures, using Linux's tracer function ftrace. The system then mapseach call to corresponding TCP-IP flow information using the mapprovided by the pseudo file procfs:/proc/net/tcp.

In some implementations, the system traces calls to thetcp_retransmit_skb() function using a tracer function developed based onthe Kprobe mechanism in Linux. This tracer function can directly returnthe TCP-IP flow information associated with a call to thetcp_retransmit_skb() function and thus remove the need for usingprocfs:/proc/net/tcp.

The system computes a total retransmission count for each network flow,e.g., over a specified time window, of the one or more network flows(606) and determines if that count exceeds a threshold (608). Thethreshold can be any suitable value, such as one.

The system then classifies each network flow (610) based on whether thetotal retransmission count for the network flow exceeds the threshold.For example, if the system determines that the total retransmissioncount for the network flow exceeds the threshold, the system canclassify the network flow as having a high retransmission count. If thesystem determines that the total retransmission count for the networkflow does not exceed the threshold, the system can classify the networkflow as not having a high retransmission count.

FIG. 7 is a flow diagram of an example process 700 for detecting hostfailures. The process 700 will be described with respect to a systemthat can perform the process, e.g., the network diagnostic engine 101 ofFIG. 1.

The system requests that a source host sends a status inquiry packet tothe destination host (702). In some implementations, the status inquirypacket is a packet, e.g., a UDP packet, to a port of the destinationhost that by convention is not listened to by any application on a host,e.g., ports with port number equal to or greater than 33434. The sourcehost may send the status inquiry packet to the destination host over apath other than the path for transmitting packets of a network flow fromthe source host to the destination host.

The system determines if the source host has received a status inquiryresponse packet from the destination host (704). The status inquiryresponse packet indicates that the destination host has received thestatus inquiry packet. In some implementations, when the status inquirypacket is a packet to a port of the destination host that by conventionis not listened to by any application on a host, the status inquiryresponse packet is an ICMP port-unreachable packet. The ICMPport-unreachable packet can copy identifying information about thestatus inquiry packet in its ICMP body if such identifying informationis supplied in a portion, e.g., the first 64 bytes, of the statusinquiry packet.

The system determines whether the destination host has failed (706)based on whether the source host has received the status inquiryresponse packet. If the system determines that the source host has notreceived the status inquiry response packet, the system determines thatthe destination host has failed. If the system determines that sourcehost has received the status inquiry response packet, the systemdetermines that the destination host has not failed.

FIG. 8 is a flow diagram of an example process for generating a graphwith network link reliability information. The process can be performedby a system of one or more computers, e.g., the network diagnosticengine 101 of FIG. 1.

The system obtains a map of a computer network, e.g., from a databaseincluding information about network devices, (802) and constructs agraph based on the network map (804). The graph includes edgescorresponding to links in the computer network, nodes corresponding toswitches and optionally hosts in the computer network, and edge weightscorresponding to an estimate of reliability of the link.

The system obtains probe results from switches in the computer network(806) and processes the probe results to determine a visit count and afailure count for each link in the graph (808).

In some implementations, the system processes probe results to generatea probe record corresponding to each probing task of a monitorednetwork, e.g., using end-to-end probing, trace probing, or both. Theprobe record for each probing task shows the hops that a diagnosticpacket has successfully reached during the probing task. The system thenprocesses probe records to determine visit counts and failure counts forlinks in the computer network. Each time a probe record indicates that adiagnostic packet has reached a switch or a host through a link, thesystem increments the visit count for the link. Each time a probe recordindicates that a diagnostic packet has reached a particular switch asits last hop but has not reached its intended destination, the systemincrements the failure count for every link between the last hop and theintended destination.

The system uses the visit count and failure count for each link todetermine an estimate of reliability for each link (806). The systemwill decrease the estimate of reliability of a link based on the failurecount for the link. However, the system can assign a low estimate ofreliability to a link even when the link has a low failure count, forexample if a link has a visit count that is higher than a thresholdindicating likely congestion of the link and/or if the link has a visitcount that is lower than a threshold indicating likely unreachability oflink. Example techniques for assigning a low estimate of reliability toa link even when the link has a low failure count are described abovewith reference to the false positive detector 223 in FIG. 2.

The system then marks the graph based on estimates of reliability foreach link (808). In some implementations, the system assigns a weight ora label to an edge in the graph corresponding to a link based on theestimate of the probability of the link. For example, the system assignsa lower weight to an edge corresponding to a link to indicate that thelink has a lower estimate of probability.

In this specification the term “engine” will be used broadly to refer toa software based system or subsystem that can perform one or morespecific functions. Generally, an engine will be implemented as one ormore software modules or components, installed on one or more computersin one or more locations. In some cases, one or more computers will bededicated to a particular engine; in other cases, multiple engines canbe installed and running on the same computer or computers.

Embodiments of the subject matter and the functional operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly-embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Embodiments of the subject matter described in thisspecification can be implemented as one or more computer programs, i.e.,one or more modules of computer program instructions encoded on atangible non transitory program carrier for execution by, or to controlthe operation of, data processing apparatus. Alternatively or inaddition, the program instructions can be encoded on an artificiallygenerated propagated signal, e.g., a machine-generated electrical,optical, or electromagnetic signal, that is generated to encodeinformation for transmission to suitable destination apparatus forexecution by a data processing apparatus. The computer storage mediumcan be a machine-readable storage device, a machine-readable storagesubstrate, a random or serial access memory device, or a combination ofone or more of them.

The term “data processing apparatus” encompasses all kinds of apparatus,devices, and machines for processing data, including by way of example aprogrammable processor, a computer, or multiple processors or computers.The apparatus can include special purpose logic circuitry, e.g., an FPGA(field programmable gate array) or an ASIC (application specificintegrated circuit). The apparatus can also include, in addition tohardware, code that creates an execution environment for the computerprogram in question, e.g., code that constitutes processor firmware, aprotocol stack, a database management system, an operating system, or acombination of one or more of them.

A computer program (which may also be referred to or described as aprogram, software, a software application, a module, a software module,a script, or code) can be written in any form of programming language,including compiled or interpreted languages, or declarative orprocedural languages, and it can be deployed in any form, including as astandalone program or as a module, component, subroutine, or other unitsuitable for use in a computing environment. A computer program may, butneed not, correspond to a file in a file system. A program can be storedin a portion of a file that holds other programs or data, e.g., one ormore scripts stored in a markup language document, in a single filededicated to the program in question, or in multiple coordinated files,e.g., files that store one or more modules, sub programs, or portions ofcode. A computer program can be deployed to be executed on one computeror on multiple computers that are located at one site or distributedacross multiple sites and interconnected by a communication network.

The processes and logic flows described in this specification can beperformed by one or more programmable computers executing one or morecomputer programs to perform functions by operating on input data andgenerating output. The processes and logic flows can also be performedby, and apparatus can also be implemented as, special purpose logiccircuitry, e.g., an FPGA (field programmable gate array) or an ASIC(application specific integrated circuit).

Computers suitable for the execution of a computer program include, byway of example, can be based on general or special purposemicroprocessors or both, or any other kind of central processing unit.Generally, a central processing unit will receive instructions and datafrom a read only memory or a random access memory or both. The essentialelements of a computer are a central processing unit for performing orexecuting instructions and one or more memory devices for storinginstructions and data. Generally, a computer will also include, or beoperatively coupled to receive data from or transfer data to, or both,one or more mass storage devices for storing data, e.g., magnetic,magneto optical disks, or optical disks. However, a computer need nothave such devices. Moreover, a computer can be embedded in anotherdevice, e.g., a mobile telephone, a personal digital assistant (PDA), amobile audio or video player, a game console, a Global PositioningSystem (GPS) destination, or a portable storage device, e.g., auniversal serial bus (USB) flash drive, to name just a few.

Computer readable media suitable for storing computer programinstructions and data include all forms of nonvolatile memory, media andmemory devices, including by way of example semiconductor memorydevices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks,e.g., internal hard disks or removable disks; magneto optical disks; andCD ROM and DVD-ROM disks. The processor and the memory can besupplemented by, or incorporated in, special purpose logic circuitry.

To send for interaction with a user, embodiments of the subject matterdescribed in this specification can be implemented on a computer havinga display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystaldisplay) monitor, for displaying information to the user and a keyboardand a pointing device, e.g., a mouse or a trackball, by which the usercan send input to the computer. Other kinds of devices can be used tosend for interaction with a user as well; for example, feedback providedto the user can be any form of sensory feedback, e.g., visual feedback,auditory feedback, or tactile feedback; and input from the user can bereceived in any form, including acoustic, speech, or tactile input. Inaddition, a computer can interact with a user by sending documents toand receiving documents from a device that is used by the user; forexample, by sending web pages to a web browser on a user's client devicein response to requests received from the web browser.

Embodiments of the subject matter described in this specification can beimplemented in a computing system that includes a back end component,e.g., as a data server, or that includes a middleware component, e.g.,an application server, or that includes a front end component, e.g., aclient computer having a graphical user interface or a Web browserthrough which a user can interact with an implementation of the subjectmatter described in this specification, or any combination of one ormore such back end, middleware, or front end components. The componentsof the system can be interconnected by any form or medium of digitaldata communication, e.g., a communication network. Examples ofcommunication networks include a local area network (“LAN”) and a widearea network (“WAN”), e.g., the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network.

The relationship of client and server arises by virtue of computerprograms running on the respective computers and having a client-serverrelationship to each other.

While this specification contains many specific implementation details,these should not be construed as limitations on the scope of anyinvention or of what may be claimed, but rather as descriptions offeatures that may be specific to particular embodiments of particularinventions. Certain features that are described in this specification inthe context of separate embodiments can also be implemented incombination in a single embodiment. Conversely, various features thatare described in the context of a single embodiment can also beimplemented in multiple embodiments separately or in any suitablesubcombination. Moreover, although features may be described above asacting in certain combinations and even initially claimed as such, oneor more features from a claimed combination can in some cases be excisedfrom the combination, and the claimed combination may be directed to asubcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various system modulesand components in the embodiments described above should not beunderstood as requiring such separation in all embodiments, and itshould be understood that the described program components and systemscan generally be integrated together in a single software product orpackaged into multiple software products.

Particular embodiments of the subject matter have been described. Otherembodiments are within the scope of the following claims. For example,the actions recited in the claims can be performed in a different orderand still achieve desirable results. As one example, the processesdepicted in the accompanying figures do not necessarily require theparticular order shown, or sequential order, to achieve desirableresults. In certain implementations, multitasking and parallelprocessing may be advantageous.

1-19. (canceled)
 20. A method comprising: identifying a particular pathof a network flow in a computer network between a source and adestination, wherein the particular path comprises one or more networkdevices coupled by one or more links; and in response to a determinationthat there is no end-to-end connectivity between the source and thedestination along the particular path, determining whether a networkcomponent of the particular path in the network flow has failedcomprising: requesting that the destination transmit a respective tracediagnostic packet to each network device along the particular path,wherein each trace diagnostic packet is configured to follow theparticular path and has a particular value in a time-to-live fieldconfigured to cause a corresponding network device to send at least atime exceeded message in response to that trace diagnostic packet,wherein the time exceeded message includes a portion of the tracediagnostic packet that includes a packet identifier inserted into afirst plurality of bits of the trace diagnostic packet; and determiningwhether at least one network component that is part of the particularpath of the network flow has failed based on results of the tracediagnostic packets.
 21. The method of claim 20, wherein determiningwhether at least one network component has failed comprises: determiningwhether the destination has received a time exceeded message from aparticular network device; in response to determining that thedestination has received the time exceeded message from a particularnetwork device, determining that the particular network device isoperational from the source along the particular path; and in responseto determining that the destination has not received the time exceededmessage from a particular network device, determining that theparticular network device has failed from the source along theparticular path.
 22. The method of claim 20, wherein the time exceededmessage is an internet control message protocol (ICMP) messagecomprising a header portion and a body portion, wherein the headerportion comprises an 8-bit type field and an 8-bit code field set asrespective values to indicate that the ICMP message is a time exceededmessage.
 23. The method of claim 20, wherein the time exceeded messageis an internet control message protocol (ICMP) message comprising thefirst plurality of bits of the trace diagnostic packet that trigger thetime exceeded message, wherein the first plurality of bits are the first64 bits of the trace diagnostic packet.
 24. The method of claim 20,wherein the first plurality of bits of the trace diagnostic packet wherethe packet identifier is inserted comprise one of a sequence number of aTCP packet or a length field of a UDP packet.
 25. The method of claim20, further comprising: estimating a low reliability for a link of theone or more links in the particular path based on a count of tracediagnostics packets observed to have traveled the link; determining thelow reliability corresponds to a low utilization of the link; and inresponse, determining that the estimated low reliability for the link isa false positive detection.
 26. The method of claim 20, wherein thedetermination that there is no end-to-end connectivity between thesource and the destination comprises: performing a first probe todetermine whether there is end-to-end connectivity between the sourceand the destination including requesting that the destination transmitan end-to-end diagnostic packet to the source, wherein the end-to-enddiagnostic packet includes information comprising a source identifierfield and a destination identifier field that include identifiers forthe source and destination, respectively, that match the packets in thenetwork flow between the source and destination such that one or morenetwork devices in the computer network forward the end-to-enddiagnostic packet on the particular path of the network flow.
 27. Asystem comprising: one or more computers and one or more storage devicesstoring instructions that are operable, when executed by the one or morecomputers, to cause the one or more computers to perform operationscomprising: identifying a particular path of a network flow in acomputer network between a source and a destination, wherein theparticular path comprises one or more network devices coupled by one ormore links; and in response to a determination that there is noend-to-end connectivity between the source and the destination along theparticular path, determining whether a network component of theparticular path in the network flow has failed comprising: requestingthat the destination transmit a respective trace diagnostic packet toeach network device along the particular path, wherein each tracediagnostic packet is configured to follow the particular path and has aparticular value in a time-to-live field configured to cause acorresponding network device to send at least a time exceeded message inresponse to that trace diagnostic packet, wherein the time exceededmessage includes a portion of the trace diagnostic packet that includesa packet identifier inserted into a first plurality of bits of the tracediagnostic packet; and determining whether at least one networkcomponent that is part of the particular path of the network flow hasfailed based on results of the trace diagnostic packets.
 28. The systemof claim 27, wherein determining whether at least one network componenthas failed comprises: determining whether the destination has received atime exceeded message from a particular network device; in response todetermining that the destination has received the time exceeded messagefrom a particular network device, determining that the particularnetwork device is operational from the source along the particular path;and in response to determining that the destination has not received thetime exceeded message from a particular network device, determining thatthe particular network device has failed from the source along theparticular path.
 29. The system of claim 27, wherein the time exceededmessage is an internet control message protocol (ICMP) messagecomprising a header portion and a body portion, wherein the headerportion comprises an 8-bit type field and an 8-bit code field set asrespective values to indicate that the ICMP message is a time exceededmessage.
 30. The system of claim 27, wherein the time exceeded messageis an internet control message protocol (ICMP) message comprising thefirst plurality of bits of the trace diagnostic packet that trigger thetime exceeded message, wherein the first plurality of bits are the first64 bits of the trace diagnostic packet.
 31. The system of claim 27,wherein the first plurality of bits of the trace diagnostic packet wherethe packet identifier is inserted comprise one of a sequence number of aTCP packet or a length field of a UDP packet.
 32. The system of claim27, further comprising: estimating a low reliability for a link of theone or more links in the particular path based on a count of tracediagnostics packets observed to have traveled the link; determining thelow reliability corresponds to a low utilization of the link; and inresponse, determining that the estimated low reliability for the link isa false positive detection.
 33. The system of claim 27, wherein thedetermination that there is no end-to-end connectivity between thesource and the destination comprises: performing a first probe todetermine whether there is end-to-end connectivity between the sourceand the destination including requesting that the destination transmitan end-to-end diagnostic packet to the source, wherein the end-to-enddiagnostic packet includes information comprising a source identifierfield and a destination identifier field that include identifiers forthe source and destination, respectively, that match the packets in thenetwork flow between the source and destination such that one or morenetwork devices in the computer network forward the end-to-enddiagnostic packet on the particular path of the network flow.
 34. One ormore non-transitory computer storage media encoded with computer programinstructions that when executed by one or more computers cause the oneor more computers to perform operations comprising: identifying aparticular path of a network flow in a computer network between a sourceand a destination, wherein the particular path comprises one or morenetwork devices coupled by one or more links; and in response to adetermination that there is no end-to-end connectivity between thesource and the destination along the particular path, determiningwhether a network component of the particular path in the network flowhas failed comprising: requesting that the destination transmit arespective trace diagnostic packet to each network device along theparticular path, wherein each trace diagnostic packet is configured tofollow the particular path and has a particular value in a time-to-livefield configured to cause a corresponding network device to send atleast a time exceeded message in response to that trace diagnosticpacket, wherein the time exceeded message includes a portion of thetrace diagnostic packet that includes a packet identifier inserted intoa first plurality of bits of the trace diagnostic packet; anddetermining whether at least one network component that is part of theparticular path of the network flow has failed based on results of thetrace diagnostic packets.
 35. The one or more non-transitory computerstorage media of claim 34, wherein determining whether at least onenetwork component has failed comprises: determining whether thedestination has received a time exceeded message from a particularnetwork device; in response to determining that the destination hasreceived the time exceeded message from a particular network device,determining that the particular network device is operational from thesource along the particular path; and in response to determining thatthe destination has not received the time exceeded message from aparticular network device, determining that the particular networkdevice has failed from the source along the particular path.
 36. The oneor more non-transitory computer storage media of claim 34, wherein thetime exceeded message is an internet control message protocol (ICMP)message comprising a header portion and a body portion, wherein theheader portion comprises an 8-bit type field and an 8-bit code field setas respective values to indicate that the ICMP message is a timeexceeded message.
 37. The one or more non-transitory computer storagemedia of claim 34, wherein the time exceeded message is an internetcontrol message protocol (ICMP) message comprising the first pluralityof bits of the trace diagnostic packet that trigger the time exceededmessage, wherein the first plurality of bits are the first 64 bits ofthe trace diagnostic packet.
 38. The one or more non-transitory computerstorage media of claim 34, wherein the first plurality of bits of thetrace diagnostic packet where the packet identifier is inserted compriseone of a sequence number of a TCP packet or a length field of a UDPpacket.
 39. The one or more non-transitory computer storage media ofclaim 34, further comprising: estimating a low reliability for a link ofthe one or more links in the particular path based on a count of tracediagnostics packets observed to have traveled the link; determining thelow reliability corresponds to a low utilization of the link; and inresponse, determining that the estimated low reliability for the link isa false positive detection.
 40. The one or more non-transitory computerstorage media of claim 34, wherein the determination that there is noend-to-end connectivity between the source and the destinationcomprises: performing a first probe to determine whether there isend-to-end connectivity between the source and the destination includingrequesting that the destination transmit an end-to-end diagnostic packetto the source, wherein the end-to-end diagnostic packet includesinformation comprising a source identifier field and a destinationidentifier field that include identifiers for the source anddestination, respectively, that match the packets in the network flowbetween the source and destination such that one or more network devicesin the computer network forward the end-to-end diagnostic packet on theparticular path of the network flow.